Applications designed to run on a specific computing platform do not operate on different computing platforms. Generally, software is inextricably linked to the specific computing platform for which it is designed to operate. For example, software written and compiled to operate within minicomputer running a specific implementation of the Unix operating system will not function within a hand-held computer using a proprietary operating system.
A computing platform typically includes an operating system (OS) and computing hardware architecture. Examples of OSs include these Microsoft® operating systems: MS-DOS®, Windows® XP, Windows® 2000, Windows NT® 4.0, Windows® ME, Windows® 98, and Windows® 95. Examples of computing hardware architecture include those associated with these Intel® microprocessors: 80286, Pentium®, Pentium® II, Pentium® III, and Itanium™.
Examples of computing platforms includes 16-bit platforms (such as Microsoft® MS-DOS® and Intel® 80286), 32-bit platforms (such as Microsoft® Windows® NT® and Intel® Pentium® II), and 64-bit platforms (such as Intel® Itanium™ and, for example, Windows® XP 64-bit Edition). A computing platform may also be called a platform, computing environment, or environment.
Specific versions of applications are designed to operate under a specific platform. These applications may be called “native” when they execute under their specific platform. For example, Microsoft® Office 2000 is an application designed to operate on a 32-bit platform. In other words, Microsoft® Office® 2000 is a native application relative to its 32-bit platform. However, these 32-bit applications may be called “non-native” when they execute under a different platform, such as a 64-bit platform.
An example of a program-module target platform (or simply “target platform”) is the platform that an executable program (e.g., program module, application, program) was targeted to run. For a program module, its target platform is also its native platform. For example, if one builds a Microsoft® Office® application to run under Windows® 2000 32-bit X86 OS environment then for that image target platform would be 32-bit x86.
An application program is the primary example of a “program module” as the term is used herein. However, the term “program module” includes other executable software that may not be labeled an application.
Typical Computer Architecture
Typical computer architecture is multi-layered. From the bottom up, it includes the hardware layer, the operating system (OS) layer, and the application layer. Alternatively, these layers may be described as the hardware layer, the kernel mode layer, and the user mode layer.
FIG. 1 illustrates the layers of typical computer architecture 100. The top of the architecture is the user mode 110. It includes applications, such as applications 112a–e. These applications communicate with a set of APIs 120. Typically, this API set is considered part of the OS, and thus, part of the computing platform.
The next layer of the architecture is the kernel mode 130. This may be generally called the “kernel” of the OS. Since it is part of the OS, it is part of the computing platform.
A kernel of an OS is the privileged part of the OS—the most trusted part of the OS. It is an inner layer of code. It typically operates I/O 132, security 134, display control (i.e., access to the screen) 136, memory management 138, and other privileged functions 139. The kernel has sole access to the hardware in the hardware layer 150 via device drivers 142 and other hardware interfaces 144.
Kernel APIs 140 are those APIs within the kernel that arbitrate access to the kernel functions. The applications typically do not call the kernel directly. Instead, the applications call the APIs 120 and the APIs, in turn, may call the kernel (in particular the kernel APIs 140).
Although FIG. 1 does not show the components 132–144 of the kernel 130 with connections between them, these components are connected as is necessary. The coupling lines are omitted from the drawing for the sake of simplicity and clarity.
Below the kernel mode 130, there is the hardware layer 150. This layer includes all of the hardware of the actual computer. This includes the processor(s), memory, disk I/O, other I/O, etc. The platform also includes the hardware layer.
Therefore, a computing platform includes the hardware layer, the kernel layer, and typically the user-mode APIs 120.
Interoperability and Compatibility
Application compatibility has long been a major concern since computing platforms began evolving. People want to run their desired applications in their chosen platform in the ideal world. However, in the real world, it is difficult to impossible to run an application on a different host platform for which it was not designed. For example, a 32-bit x86 application cannot run on 64-bit Itanium (IA64) environment. The problem worsens when people buy a more powerful machine with a different platform than they have used previously. Immediately, all the applications from the old platform become useless.
Each platform has its corresponding body of native applications that are a designed to run under it. When a new generation of platform is released, software developers generally upgrade their products to run under the new generation platform. Software developers do this for many reasons, including marketing, technology, and economics.
For similar reasons, OS developers like their products to be backwards compatible. In this way, older generations of applications may run on the latest generation of the OS (and thus the latest generation of platform). In other words, if non-native applications can run under a native platform (including the new OS), users are encouraged to purchase the new OS because they are not forced to discard their current applications and purchase new versions. This also gives software developers time to develop upgrades to their applications.
Herein, an example of compatibility is a non-native program module functioning appropriately and peacefully co-existing with native program modules within a native computing environment (e.g., an OS).
As used herein, an example of interoperability is the ability of both native and non-native program modules to share resources (such as access data within each other's memory space or a shared memory space) and/or work together and cooperatively.
For the sake of clarity and simplicity, an example is used herein to illustrate the problem of incompatibility of non-native applications and non-interoperability between native and non-native applications. In this example, the non-native program modules are called 32-bit applications because they are designed to operate on a 32-bit platform. In this example, the native applications are called 64-bit applications because they are designed to operate on the native platform, which is 64-bit. This is provided as one example and not for limitation. Those of ordinary skill in the art understand and appreciate that there exists other combinations of native and non-native applications and native platforms.
Running Non-Native Applications on a Native Platform
Consider this: Running non-native applications on a native platform. More specifically, consider this example: Running 32-bit applications in a 64-bit environment. Assume, for this example, that the 64-bit platform is an upgrade to an existing popular 32-bit platform (on which the 32-bit applications are designed to run).
In computer architecture, the numbered-bit platform (e.g., 32-bit platform) typically refers to the word size of addressable memory of a platform. Typically, a word is a unit of data that is moved in a single operation from storage to a processor register. In the most familiar architectures of the past few decades, a word has been four bytes in length, or 32 bits. Both IBM's mainframe processors and Intel's processors, used in standard PCs, have used a 32-bit word. Recent processor architectures from Intel and others provide for a 64-bit word.
One advantage of a 64-bit platform over a 32-bit platform is that the much larger memory space can be addressed. Primarily, this is because an address to memory may be 64-bits long in the 64-bit platform as opposed to the typical 32-bit long address of the 32-bit platform.
Alignment of Data
Alignment is putting data into the computer memory at addresses that are more efficient for the platform to access. Typically, this is done by storing data at word boundaries of memory. This may be done at the price of wasting some memory when the data being stored is less than a word in size. However, the benefit of alignment is speed. Alignment of data stored in memory speeds memory access of such data because the computer platform is utilized most efficiently.
For example, a modern RISC platform reads from memory in multi-byte chunks, usually 4 or 8 bytes long, these chunks must begin at addresses that are multiples of the chunk size. Memory accesses to misaligned addresses are emulated by multiple aligned accesses and is much slower, or may generate bus errors and abort the program. Other platforms can handle misaligned (i.e., byte aligned) memory accesses more gracefully, but it degrades performance.
Those of ordinary skill in the art of familiar with the alignment of data and the costs and benefits of doing so.
Memory Shared by Native and Non-Native
One problem with interoperability and compatibility is managing memory shared between non-native (e.g., 32-bit) applications and native (e.g., 64-bit) applications. Another is managing memory shared between non-native (e.g., 32-bit) applications and the native (e.g., 64-bit) operating system.
This is particularly true when the memory address alignment differs between native and non-native. For example, all data is aligned in memory on four (4) byte increments in a 32-bit environment and all data is aligned on eight (8) byte increments. In such a situation, it is possible for data of a non-native application to be stored in a manner that is not aligned for the purposes of the native environment.
FIG. 2 illustrates this point. Memory blocks 210 represent a memory structure based upon a 32-bit word addressing scheme. The bold vertical lines indicate the word boundaries. 64-bits of data, labeled “A1” through “A8”, is stored in two word-sized memory locations 212 and 214. 32-bits of data, labeled “B1” through “A4”, is stored in a single word-sized memory location 216.
In FIG. 2, memory blocks 230 and 250 represent a memory structure based upon a 64-bit word addressing scheme. Again, the bold vertical lines indicate the word boundaries.
When the A1–A8 data and B1–B4 data of blocks 210 is converted for use by a 64-bit memory addressing scheme, it may stored and addressed in the manner depicted in by memory blocks 230. More specifically, this manner is un-aligned. However, the same data is stored in an aligned fashion in memory blocks 250.
Thus, when faced with the decision on whether to align data, one option to ignore the issue and allow the hardware to compensate for it. As described above and illustrated by memory blocks 230 of FIG. 2, the hardware may compensate by accessing overlapping data from more than one contiguous memory address locations. The cost of this approach is the extra time required to access data from memory. This approach is feasible only if the lost time (of multiple accesses) is tolerable.
What if the time wasted by compensating for data non-alignment within memory becomes intolerable?
Another issue is whether it is always necessary to force an alignment. Sometimes alignments happen naturally.